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DETAILED ACTION 

1 . This Office action is responsive to Applicant's submissions filed on March 23, 2007 and 
April 25, 2007. Claims 1-20 and 22-24 are pending. 

Response to Amendment 

2. The objection to the drawings has been withdrawn in view of Applicant's replacement 
drawing sheets filed on April 25, 2007. 

3. The objection to claims 19 and 23 has been withdrawn in view of Applicant's amendment 
filed on March 23,2007. 

4. The rejection of claims 1-14, 21 and 23 under 35 U.S.C. 101 has been withdrawn in view 
of Applicant's amendment filed on March 23, 2007. 

5. The rejection of claim 23 under 35 U.S.C. 1 12, second paragraph, has been withdrawn in 
view of Applicant's amendment filed on March 23, 2007. 

Response to Arguments 

6. Applicant's arguments filed on March 23, 2007 with respect to claims 1-18 and 22-24 
have been considered but are moot in view of the new ground(s) of rejection, as set forth below 
with reference to Hallem. Applicant's amendment necessitated the new ground(s) of rejection. 

7. Applicant's arguments filed on March 23, 2007 with respect to claims 19 and 20 have 
been fully considered but they are not persuasive. 
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Applicant states that independent claims 1, 15, 19, 22 and 23, as amended, "recite similar 
aspects, namely passing a user injected custom state to the plug-in condition to check a fault 
condition," and contends that Necula "does not disclose or suggest these novel aspects" 
(remarks, page 9). However, the examiner notes that independent claim 19, as amended, does 
not recite a user injected custom state. Accordingly, there is no basis for Applicant's argument 
in the claims. Although the claims are interpreted in light of the specification, limitations from 
the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1 181, 26 
USPQ2d 1057 (Fed. Cir. 1993). 

Terminal Disclaimer 

8. The terminal disclaimer filed on March 23, 2007 disclaiming the terminal portion of any 
patent granted on this application which would extend beyond the expiration date of any patent 
granted on Application No. 10/667,542 has been reviewed and is accepted. The terminal 
disclaimer has been recorded. 

Claim Rejections - 35 USC § 102 

9. The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 



10. Claims 19 and 20 are rejected under 35 U.S.C. 102(b) as being anticipated by U.S. Patent 
No. 6,128,774 to Necula et al. (art of record, "Necula"). 
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With respect to claim 19 (currently amended), Necula discloses a method of performing 
static checking of executable code comprising: 

invoking a precondition plug-in, providing the precondition plug-in with a program 
execution state (see, e.g., column 5, lines 50-60: "... the code consumer can declare a 
precondition, which is essentially a description of the calling convention the consumer will use 
when invoking the untrusted code."); 

receiving information from the precondition plug-in (see, e.g., column 5, lines 50-60); 

determining whether a fault condition exists based, at least in part, upon the information 
from the pre-condition plug-in (see, e.g., column 7, lines 21-32: "The code consumer guarantees 
that the precondition holds when the untrusted code 42 is invoked. . . . The precondition for such 
a function is a predicate that the untrusted code 42 must establish before calling the function 
...."); and 

providing information associated with the fault condition, if a fault condition is 
determined to exist (see FIG. 4 - safety predicate (SP) - and associated text, e.g., column 4, lines 
40-48: ". . . the VCGen module 32 emits a predicate that expresses the conditions under which 
the execution of the instruction is safe."). 

With respect to claim 20 (original), Necula discloses the method of claim 19, further 
comprising at least one of the following: 

invoking a postcondition plug-in, providing the postcondition plug-in with the program 
execution state (see, e.g., column 5, lines 60-65: ". . . postconditions for the untrusted code. 
These are constraints on the final execution state of the untrusted code."); and 
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receiving information from the postcondition plug-in (see, e.g., column 7, lines 21-32: 
"The untrusted code 42 must ensure that the postcondition holds on return. ... the postcondition 
is a predicate that the untrusted code 42 may assume to hold upon return from the function.") 

Claim Rejections - 35 USC §103 

1 1 . The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

12. Claims 1-6, 8-13, 15, 16 and 22-24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Necula in view of Hallem et al., "A System and Language for Building 
System-Specific, Static Analyses" (recorded on IDS dated 04/05/2004, "Hallem"). 

With respect to claim 1 (currently amended), Necula discloses a computer implemented 
executable code check system comprising: 

an input component that receives an object file and a specification associated with the 
object file (see FIGS. 3 and 4 - VCGen module 32 - and associated text, e.g., column 4, lines 
37-42: "The VCGen module 32 performs two tasks. First, it checks simple safety properties of 
the annotated executable 30. ... Second, the VCGen module 32 watches for instructions whose 
execution might violate the safety policy." The examiner notes that the object file is 
synonymous with the executable file, and the specification associated with the object file is the 
annotation embedded in the executable and/or rules defined by the safety policy.), 
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the specification comprising information associated with a plug-in condition for a method 
(see FIG. 4 - configuration data 50 - and associated text, e.g., column 7, lines 19-32: "The 
configuration data 50 also describes, by precondition-postcondition pairs, all of the functions that 
the untrusted code 42 are permitted to invoke."); and 

a checker that employs the specification to facilitate static checking of the object file, the 
checker providing information if a fault condition is determined (see FIG. 4 - VCGen module 32 
- and associated text, e.g., column 13, lines 16-26: "The safety predicate 34 for a function is 
obtained by evaluating it symbolically starting in a state that maps the global variables . . . and 
function formal parameters to new variables . . . ." FIGS. 3 and 5 - proof checker 40 - and 
associated text, e.g., column 13, lines 25-35: "FIG. 5 is a diagram illustrating an implementation 
of the proof checker module 40 of FIG. 3. The function of the proof checker module 40 is to 
verify that the proof 38 supplied by the untrusted proof producer uses only allowed axioms and 
inference rules and that it is a proof of the required safety predicate 34." VCGen and the proof 
checker perform the checking of the executable statically based on the provided specification.). 

Necula does not explicitly disclose the checker passing a user injected custom state to the 
plug-in condition to check the fault condition. 

However, in an analogous art, Hallem teaches static analysis of code (see, for example, 
page 69, Abstract). Hallem further teaches passing user-injected custom state values to 
extensions or plug-in conditions that define state machines (see, for example, page 70, section 
2.1, Metal Extensions and State Machines, first, second and third paragraphs) to check for bugs 
and fault conditions (see, for example, page 69, Introduction, second paragraph). The teachings 
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of Hallem provide flexibility and ease of use in arbitrarily extending the checker (see, for 
example, page 69, Introduction, third paragraph). 

One of ordinary skill in the art could, with predictable results, implement the teachings of 
Necula such that the checker passes a user injected custom state to the plug-in condition to check 
the fault condition. As Hallem describes, such an implementation would provide flexibility and 
ease of use in arbitrarily extending the checker of Necula. Thus, the claimed subject matter 
would have been obvious to one of ordinary skill in the art at the time the invention was made. 

With respect to claim 2 (original), Necula and Hallem disclose the system of claim I, and 
Necula further discloses the plug-in condition comprising a precondition for the method (see 
FIG. 4 - configuration data 50 - and associated text, e.g., column 7, lines 19-32: "The 
configuration data 50 also describes, by precondition-postcondition pairs, all of the functions that 
the untrusted code 42 are permitted to invoke."). 

With respect to claim 3 (original), Necula and Hallem disclose the system of claim 2, and 
Necula further discloses the checker providing information associated with an object's state after 
a call to the method, the information being based, at least in part, upon the plug-in precondition 
(see FIG. 4 - VCGen module 32 - and associated text, e.g., column 13, lines 16-24: "The safety 
predicate 34 for a function is obtained by evaluating it symbolically starting in a state that maps 
the global variables . . . and function formal parameters to new variables . . . ."). 

With respect to claim 4 (original), Necula and Hallem disclose the system of claim 1, and 
Necula further discloses the plug-in condition comprising a postcondition for the method (see 
FIG. 4 - configuration data 50 - and associated text, e.g., column 7, lines 19-32: "The 
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configuration data 50 also describes, by precondition-postcondition pairs, all of the functions that 
the untrusted code 42 are permitted to invoke."). 

With respect to claim 5 (original), Necula and Hallem disclose the system of claim 4, and 
Necula further discloses the checker providing information associated with an object's state after 
a call to the method, the information being based, at least in part, upon the plug-in postcondition 
(see FIG. 4 - VCGen module 32 - and associated text, e.g., column 13, lines 16-24: "The safety 
predicate 34 for a function is obtained by evaluating it symbolically starting in a state that maps 
the global variables . . . and function formal parameters to new variables . . . ."). 

With respect to claim 6 (original), Necula and Hallem disclose the system of claim 1 , and 
Necula further discloses the object file being based, at least in part, upon a language that 
compiles to Common Language Runtime (see, e.g., column 1, lines 40-55: "High level type-safe 
programming languages, such as ML and Java ... in practice programs often have some 
components written in ML or Java and other components written in different languages (e.g. C or 
assembly language)." According to the Meijer reference cited below, languages such as C 
compile to the Common Language Runtime.) 

With respect to claim 8 (original), Necula and Hallem disclose the system of claim 1, and 
Hallem further discloses the specification comprising information associated with a state- 
machine protocol (see, for example, page 70, section 2.1, Metal Extensions and State Machines, 
first paragraph). 
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With respect to claim 9 (original), Necula and Hallem disclose the system of claim 8, and 
Hallem further discloses a state of an object modeled with a custom state (see, for example, page 
71, section 3.1, Metal States, second paragraph). 

With respect to claim 10 (original), Necula and Hallem disclose the system of claim 9, 
and Hallem further discloses the state of the object further being modeled with a custom state 
component (see, for example, page 71, section 3.1, Metal States, fifth paragraph). 

With respect to claim 1 1 (original), Necula and Hallem disclose the system of claim 10, 
and further disclose the specification comprising at least one of a plug-in precondition and a 
plug-in postcondition method, which is a method of the custom state that is invoked by the 
checker to perform interface-specific state checks and state transitions (see Necula, FIG. 4 - 
configuration data 50 - and associated text, e.g., column 7, lines 19-32: "The configuration data 
50 also describes, by precondition-postcondition pairs, all of the functions that the untrusted code 
42 are permitted to invoke." Hallem, pages 70-71, section 2.1, Metal Extensions and State 
Machines, sixth and seventh paragraphs: "Each state value defines a list of transitions. In the 
free checker, the start state defines a single transition rule and the v. freed state defines two."). 

With respect to claim 12 (original), Necula and Hallem disclose the system of claim 1, 
and Necula further discloses wherein the specification is embedded with the object file (see FIG. 
4 - annotated executable 30 - and associated text, e.g., column 5, line 66 to column 6, line 4. 
The annotations are embedded with the executable.). 
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With respect to claim 13 (original), Necula and Hallem disclose the system of claim 1, 
and Necula further discloses wherein the specification is stored in a specification repository (see 
FIG. 4 - configuration data 50 - and associated text, e.g., column 6, lines 55-59: "... a file of 
configuration data 50, which is provided as part of the safety policy by the code consumer." A 
file is stored in memory, e.g., in a file repository, and separate from the executable.). 

With respect to claim 15 (currently amended), Necula discloses a method of facilitating 
static checking of executable code comprising: 

receiving executable code (see FIG. 3 - annotated executable 30 - and associated text, 
e.g., column 4, lines 32-35); 

receiving a specification associated with the executable code, the specification 
comprising information associated with at least one of a precondition or a postcondition for a 
method (see FIGS. 3 and 4 - VCGen module 32 - and associated text, e.g., column 4, lines 37- 
42: "The VCGen module 32 performs two tasks. First, it checks simple safety properties of the 
annotated executable 30. ... Second, the VCGen module 32 watches for instructions whose 
execution might violate the safety policy." FIG. 4 - configuration data 50 - and associated text, 
e.g., column 7, lines 19-32: "The configuration data 50 also describes, by precondition- 
postcondition pairs, all of the functions that the untrusted code 42 are permitted to invoke." The 
examiner notes that the specification associated with the executable code is the annotation 
embedded in the executable and/or rules defined by the safety policy.); 

statically applying the specification to the executable code (see FIG. 4 - VCGen module 
32 - and associated text, e.g., column 13, lines 16-24: "The safety predicate 34 for a function is 
obtained by evaluating it symbolically starting in a state that maps the global variables . . . and 
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function formal parameters to new variables . . . ." FIGS. 3 and 5 - proof checker 40 - and 
associated text, e.g., column 13, lines 25-35: "FIG. 5 is a diagram illustrating an implementation 
of the proof checker module 40 of FIG. 3. The function of the proof checker module 40 is to 
verify that the proof 38 supplied by the untrusted proof producer uses only allowed axioms and 
inference rules and that it is a proof of the required safety predicate 34." VCGen and proof 
checker perform the checking of the executable statically based on the provided specification). 

Necula does not explicitly disclose passing a user injected custom state to the at least one 
precondition or postcondition. 

However, in an analogous art, Hallem teaches static analysis of code (see, for example, 
page 69, Abstract). Hallem further teaches passing user-injected custom state values to 
extensions or plug-in conditions that define state machines (see, for example, page 70, section 
2.1, Metal Extensions and State Machines, first, second and third paragraphs) to check for bugs 
and fault conditions (see, for example, page 69, Introduction, second paragraph). The teachings 
of Hallem provide flexibility and ease of use in arbitrarily extending the checker (see, for 
example, page 69, Introduction, third paragraph). 

One of ordinary skill in the art could, with predictable results, implement the teachings of 
Necula so as to pass a user injected custom state to the at least one precondition or postcondition. 
As Hallem describes, such an implementation would provide flexibility and ease of use in 
arbitrarily extending the checker of Necula. Thus, the claimed subject matter would have been 
obvious to one of ordinary skill in the art at the time the invention was made. 

Necula further discloses: 
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determining whether a fault condition exists based, at least in part, upon the statically 
applied specification; and, 

providing information associated with the fault condition, if a fault condition is 
determined to exist. 

(see FIG. 4 - safety predicate (SP) - and associated text, e.g., column 4, lines 40-48: 
"The VCGen module 32 emits a predicate that expresses the conditions under which the 
execution of the instruction is safe.") 

With respect to claim 16 (original), Necula and Hallem disclose the method of claim 15, 
and Necula further discloses a computer readable medium having stored thereon computer 
executable instructions for carrying out the method of claim 15 (see FIG. 6 and column 16, lines 
25-30: "Software verification modules 66, of the type disclosed herein in conjunction with the 
present invention, are stored in the computer storage devices 64."). 

With respect to claim 22 (currently amended), Necula discloses a computer readable 
medium storing computer executable components of an executable code check system (see FIG. 
6 and column 16, lines 25-30: "Software verification modules 66, of the type disclosed herein in 
conjunction with the present invention, are stored in the computer storage devices 64.") 
comprising: 

an input component that receives an object file and a specification associated with the 
object file (see FIGS. 3 and 4 - VCGen module 32 - and associated text, e.g., column 4, lines 
37-42: "The VCGen module 32 performs two tasks. First, it checks simple safety properties of 
the annotated executable 30. ... Second, the VCGen module 32 watches for instructions whose 
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execution might violate the safety policy." The examiner notes that the object file is 
synonymous with the executable file, and the specification associated with the object file is the 
annotation embedded in the executable and/or rules defined by the safety policy.), 

the specification comprising information associated with a plug-in condition for a method 
(see FIG. 4 - configuration data 50 - and associated text, e.g., column 7, lines 19-32: "The 
configuration data 50 also describes, by precondition-postcondition pairs, all of the functions that 
the untrusted code 42 are permitted to invoke."); and 

a checker component that employs the specification to facilitate static checking of the 
object file, the checker component providing information if a fault condition is determined (see 
FIG. 4 - VCGen module 32 - and associated text, e.g., column 13, lines 16-26: "The safety 
predicate 34 for a function is obtained by evaluating it symbolically starting in a state that maps 
the global variables . . . and function formal parameters to new variables . . . ." FIGS. 3 and 5 - 
proof checker 40 - and associated text, e.g., column 13, lines 25-35: "FIG. 5 is a diagram 
illustrating an implementation of the proof checker module 40 of FIG. 3. The function of the 
proof checker module 40 is to verify that the proof 38 supplied by the untrusted proof producer 
uses only allowed axioms and inference rules and that it is a proof of the required safety 
predicate 34." VCGen and the proof checker perform the checking of the executable statically 
based on the provided specification.). 

Necula does not explicitly disclose the checker component passing a user injected custom 
state to the plug-in condition to check the fault condition. 

However, in an analogous art, Hallem teaches static analysis of code (see, for example, 
page 69, Abstract). Hallem further teaches passing user-injected custom state values to 
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extensions or plug-in conditions that define state machines (see, for example, page 70, section 
2.1, Metal Extensions and State Machines, first, second and third paragraphs) to check for bugs 
and fault conditions (see, for example, page 69, Introduction, second paragraph). The teachings 
of Hallem provide flexibility and ease of use in arbitrarily extending the checker (see, for 
example, page 69, Introduction, third paragraph). 

One of ordinary skill in the art could, with predictable results, implement the teachings of 
Necula such that the checker component passes a user injected custom state to the plug-in 
condition to check the fault condition. As Hallem describes, such an implementation would 
provide flexibility and ease of use in arbitrarily extending the checker of Necula. Thus, the 
claimed subject matter would have been obvious to one of ordinary skill in the art at the time the 
invention was made. 

With respect to claim 23 (currently amended), Necula discloses a computer implemented 
executable code check system (see FIG. 6) comprising: 

means for receiving a specification associated with an object file, the specification 
comprising information associated with a plug-in condition for a method (see FIGS. 3 and 4 - 
VCGen module 32 - and associated text, e.g., column 4, lines 37-42: "The VCGen module 32 
performs two tasks. First, it checks simple safety properties of the annotated executable 30. ... 
Second, the VCGen module 32 watches for instructions whose execution might violate the safety 
policy." FIG. 4 - configuration data 50 - and associated text, e.g., column 7, lines 19-32: "The 
configuration data 50 also describes, by precondition-postcondition pairs, all of the functions that 
the untrusted code 42 are permitted to invoke." The examiner notes that the object file is 
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synonymous with the executable file, and the specification associated with the object file is the 
annotation embedded in the executable and/or rules defined by the safety policy.); 

means for statically checking the object file based, at least in part, upon the specification 
and determining if a fault condition exists (see FIG. 4 - VCGen module 32 - and associated text, 
e.g., column 13, lines 16-26: "The safety predicate 34 for a function is obtained by evaluating it 
symbolically starting in a state that maps the global variables . . . and function formal parameters 
to new variables . . . ." FIGS. 3 and 5 - proof checker 40 - and associated text, e.g., column 13, 
lines 25-35: "FIG. 5 is a diagram illustrating an implementation of the proof checker module 40 
of FIG. 3. The function of the proof checker module 40 is to verify that the proof 38 supplied by 
the untrusted proof producer uses only allowed axioms and inference rules and that it is a proof 
of the required safety predicate 34." VCGen and the proof checker perform the checking of the 
executable statically based on the provided specification.). 

Necula does not explicitly disclose means for passing a user injected custom state to the 
plug-in condition. 

However, in an analogous art, Hallem teaches static analysis of code (see, for example, 
page 69, Abstract). Hallem further teaches passing user-injected custom state values to 
extensions or plug-in conditions that define state machines (see, for example, page 70, section 
2.1, Metal Extensions and State Machines, first, second and third paragraphs) to check for bugs 
and fault conditions (see, for example, page 69, Introduction, second paragraph). The teachings 
of Hallem provide flexibility and ease of use in arbitrarily extending the checker (see, for 
example, page 69, Introduction, third paragraph). 
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One of ordinary skill in the art could, with predictable results, implement the teachings of 
Necula so as to pass a user injected custom state to the plug-in condition. As Hallem describes, 
such an implementation would provide flexibility and ease of use in arbitrarily extending the 
checker of Necula. Thus, the claimed subject matter would have been obvious to one of ordinary 
skill in the art at the time the invention was made. 

Necula further discloses: 

means for providing information if a fault condition is determined to exist (see FIG. 4 - 
safety predicate (SP) - and associated text, e.g., column 4, lines 41-48: ". . . the VCGen module 
32 emits a predicate that expresses the conditions under which the execution of the instruction is 
safe."). 

With respect to claim 24 (currently amended), Necula discloses a method of performing 
static checking of executable code comprising: 

receiving a request, the request including a parameter (see FIG. 4 - VCGen module 32 - 
and associated text, e.g., column 5, lines 60-65: "Both the precondition and postcondition are 
parameters of the VCGen module 32 and are part of the safety policy." VCGen thus receives 
precondition and postcondition parameters from configuration data file.); 

setting a type of a result of a method call to a type of the parameter (The method or 
function call is directly controlled by the parameter, i.e. preconditions and postconditions, and 
thus they must be of the same type.); and 

employing the parameter only during static checking of the method (see FIG. 4 - VCGen 
module 32 - and associated text, e.g., column 13, lines 16-26: "The safety predicate 34 for a 
function is obtained by evaluating it symbolically starting in a state that maps the global 
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variables . . . and function formal parameters to new variables . . . ." FIGS. 3 and 5 - proof 
checker 40 - and associated text, e.g., column 13, lines 25-35: "FIG. 5 is a diagram illustrating 
an implementation of the proof checker module 40 of FIG. 3. The function of the proof checker 
module 40 is to verify that the proof 38 supplied by the untrusted proof producer uses only 
allowed axioms and inference rules and that it is a proof of the required safety predicate 34." 
VCGen and the proof checker perform the checking of the executable statically based on the 
provided specification.). 

Necula does not explicitly disclose performing component-wise comparison of a user 
injected custom state and a state defined by the parameter to determine a fault condition. 

However, in an analogous art, Hallem teaches static analysis of code (see, for example, 
page 69, Abstract). Hallem further teaches passing user-injected custom state values to 
extensions or plug-in conditions that define state machines (see, for example, page 70, section 
2.1, Metal Extensions and State Machines, first, second and third paragraphs) to check for bugs 
and fault conditions (see, for example, page 69, Introduction, second paragraph). The teachings 
of Hallem provide flexibility and ease of use in arbitrarily extending the checker (see, for 
example, page 69, Introduction, third paragraph). 

One of ordinary skill in the art could, with predictable results, implement the teachings of 
Necula so as perform component- wise comparison of a user injected custom state and a state 
defined by the parameter to determine a fault condition. As Hallem describes, such an 
implementation would provide flexibility and ease of use in arbitrarily extending the checker of 
Necula. Thus, the claimed subject matter would have been obvious to one of ordinary skill in the 
art at the time the invention was made. 
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13. Claim 7 is rejected under 35 U.S.C. 103(a) as being unpatentable over Necula in view of 
Hallem, as applied to claim 1 above, and further in view of Meijer et al, "Technical Overview of 
the Common Language Runtime" (art of record, "Meijer"). 

With respect to claim 7 (original), Necula and Hallem disclose the system of claim 1, but 
do not explicitly disclose the object file being based, at least in part, upon at least one of C#, 
Visual Basic.net and Managed C++. 

However, Necula discloses that the executable, i.e. object file, is compiled from type-safe 
and/or non-type-safe languages (see, e.g., column 1, lines 40-55: "High level type-safe 
programming languages, such as ML and Java ... in practice programs often have some 
components written in ML or Java and other components written in different languages (e.g. C or 
assembly language)."). Meijer discloses that the Common Language Runtime (CLR), which is 
expressed in the Common Intermediate Language (CIL), can be compiled from a language such 
as C, Pascal, C#, etc. (see, e.g., Introduction). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use one of C#, Visual Basic.net and Managed C++ as a programming 
language in Necula's invention because these statically typed object-oriented languages are well 
supported by Microsoft's Common Language Infrastructure (CLI), as disclosed in Meijer, which 
in turn provides strong support for CLR. 

14. Claim 14 is rejected under 35 U.S.C. 103(a) as being unpatentable over Necula in view of 
Hallem, as applied to claim 1 above, and further in view of U.S. Patent No. 6,571,232 to 
Goldberg et al. (art of record, "Goldberg"). 
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With respect to claim 14 (original), Necula and Hallem disclose the system of claim 1, 
but do not explicitly disclose the system further comprising a specification extractor that queries 
a database for its schema and stores information associated with the schema in a specification 
repository. 

However, Goldberg discloses a query object generator system comprising a specification 
extractor that queries a database for its schema and stores information associated with the 
schema in a specification repository (see FIG. 4 and associated text, e.g., column 6, lines 40-63: 
"The query object generator tool 400 includes a mechanism (not shown) for obtaining the 
database schema from database 404 . ..." FIG. 6 and associated text, e.g. column 33, lines 5-13: 
"The query object internal state object 602 allows the user to save a logical definition of a query 
object in an intermediate file, such as file 612."). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to allow the software verification system of Necula to query a database for 
its schema and store information associated with it as disclosed in Goldberg so that the system 
can further verify that command instructions in the program that are associated with database 
querying are valid. 

15. Claims 17 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Tichelaar et al., "A Metal-model for Language-Independent Refactoring" (art of record, 
"Tichelaar") in view of Hallem. 

With respect to claim 17 (currently amended), Tichelaar discloses a method of 
developing a software component comprising: 
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implementing a subclass of a custom state class (see FIG. 1 : "Class" and 
"InheritanceDefinition"); 

implementing at least one of a plug-in precondition and a plug-in postcondition as a 
method of the subclass (see Table 1 : pre- and post-conditions in "Add Method"); 

placing a custom attribute on an enclosing type declaration that references the custom 
state sub class (see Table 1 : "Add Attribute" and "Add Parameter" belonging to a subclass); 

placing an attribute on a declaration that references the at least one of a plug-in 
precondition or a plug-in postcondition (The pre- and post-conditions provide constraints for a 
declaration of a class or subclass in Table 1 . Thus, "Add Attribute" to the class or subclass with 
the pre- and post-conditions as parameters would provide the declaration of that class or subclass 
with a reference to the pre- and post-conditions.). 

Tichelaar does not explicitly disclose determining a fault condition based upon the 
information from the at least one of plug-in precondition or a plug-in postcondition. 

However, in an analogous art, Hallem teaches static analysis of code (see, for example, 
page 69, Abstract). Hallem further teaches extensions or plug-in conditions that define state 
machines (see, for example, page 70, section 2.1, Metal Extensions and State Machines, first, 
second and third paragraphs) that are employed to check for bugs and fault conditions (see, for 
example, page 69, Introduction, second paragraph). The teachings of Hallem provide flexibility 
and ease of use in arbitrarily extending the checker (see, for example, page 69, Introduction, 
third paragraph). 

One of ordinary skill in the art could, with predictable results, supplement the teachings 
of Tichelaar so as to determine a fault condition based upon the information from the at least one 
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of plug-in precondition or a plug-in postcondition. Hallem describes a flexible and easily 
extended checker that provides such determinations. Thus, the claimed subject matter would 
have been obvious to one of ordinary skill in the art at the time the invention was made. 

With respect to claim 1 8 (original), Tichelaar and Hallem disclose the method of claim 
17, but do not explicitly disclose a computer readable medium having stored thereon computer 
executable instructions for carrying out the method of claim 17. 

Nonetheless, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made that the method of claim 17 needs to be stored on a computer readable 
medium in order for the functionality it is intended to perform to be realized by a computer. 

Conclusion 

16. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 
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17. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Michael J. Yigdall whose telephone number is 571-272-3707. 
The examiner can normally be reached on Monday to Friday from 8:00 AM to 4:30 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on 571-272-3695. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you 
would like assistance from a USPTO Customer Service Representative or access to the 
automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Michael J. Yigdall 

Examiner 

Art Unit 2 192 

/MY/ 

/Tuan Q. Dam/ 

Supervisory Patent Examiner, Art Unit 2192 



